Google のソフトウェアエンジニアリング ― 持続可能なプログラミングを支える技術、文化、プロセス
本書の著者は、「ソフトウェアエンジニアリング」 を、組織が時間経過に応じてコードを構築し、保守するために用いるツールとプロセスすべてを含むものとすることを提案 コードベースを持続可能にし、ソフトウェアエンジニアリングの規律を厳格化する方法 3 つの根本的原則
時間と変化
スケールと発展
トレードオフとコスト
3 つの主要な側面
文化
プロセス
ツール
1 部 主題
1 章 ソフトウェアエンジニアリングとは何か
プログラミングとソフトウェアエンジニアリングの決定的な違い
時間、スケール、作用しているトレードオフ
効率や熱力学においてはエントロピーを考慮する必要があるように、ソフトウェアの時間による変化や保守においてはこれを意識する必要 Google の本番環境システムは人類によって造られたもっとも複雑な機械 本書の大部分は、そのような機械を生み出す組織のスケールの複雑性と、その機械を稼働させ続けるためのプロセス
Google は 2006 年にコンパイラのアップデートで困難に直面 → 技術と組織の変化の必要性を認めてそこに注力
自動化、統合 / 一貫性、専門知識
左への移動 (シフトレフト) : 問題の早期発見がコストを下げる 意思決定
意思決定の入力としてすべての情報が定量化可能な場合とそうでない場合がある
ビルド時間増大が直接自身の苦痛につながらない状態になったら、ビルド時間を減らすインセンティブが働かなくなる事例
2 部 文化
2 章 チームでうまく仕事をするには
自身が制御可能な変数 = 自分自身
ソフトウェア開発はチームによる取り組み
人は自身の進行中の作業を人に見られて批評されることに不安がある なぜ我々は個人を偶像化するのか？ → 人間には、リーダーやロールモデルを探して真似ようとする自然の本能
不安から人は自身の作業を隠蔽しようとするが、隠蔽こそが大問題
早期発見
「早期に失敗し、高速に失敗し、頻繁に失敗せよ」
知識の分散、集団的英知
早期のフィードバックループ
エンジニアには集中するための時間が必要だが、チームで協働できる環境も必要
ときどき失敗するようなことがなかったとすれば、十分に革新的ではないか、十分にリスクを取っていないかのどちらか
3 章 知識共有
組織は、組織自体の問題の大半に対し答えることができて然るべき
その状態を達成するためには次の 2 つが必要
それらの問題の答えを知る専門家
専門家の知識を流通させるメカニズム
ソフトウェアエンジニアリングの中心にいるのは人間
つまり、コードは重要な成果物ではあるが、製品開発の小さな一部にすぎない
どんな専門家もかつては初心者
組織の成功は、組織が擁する人々の育成と、その人々への投資にかかっている
専門家からの一対一の個人向けアドバイスは非常に価値が高い
専門家が休暇等でいなくなることがあるし、スケールしない
一方で、一対一のアドバイスに比べて一般的なものになる
保守コストもかかる
組織慣習的知識は、個々のチームメンバーの知識と、ドキュメント化されている知識との間にある間隙に存在 自分には常に学ぶべきことがあると認識するのが重要
常に学び続けよ、常に質問し続けよ
文脈を理解せよ
4 章 公正のためのエンジニアリング
など
卓越したエンジニアであるためには、製品の設計と実装に多様な観点を持ち込むことにも気を配らなければならない
万人に向けて製品を開発できるところまで至るには、自分たちが代表しようとしている母集団の理解がまずは不可欠
最低でも、自身が対象とするユーザーを構成している母集団の統計学的属性を理解する必要
一般的な方法論では、多数派のユースケースをまず開発し、エッジケース (edge case) に対処する改善や機能を後回しにする
まず最初に注力しなければならないのは、最も困難もしくは低代表であるユースケース
5 章 チームリーダー入門
概要
伝統的な意味での 「管理」 は行わない : リーダーシップ、影響力、チームに仕えることに集中する チームの着眼点、方向、速度に特に注意を払う
2 種の異なる役職
人は植物のようなもの
植物は、水や肥料について、それぞれ必要な量が異なる
6 章 スケールするリーダー
7 章 エンジニアリング生産性の計測
エンジニアリングの生産性それ自体に専念する専門家のチームを擁することは非常に有用かつ重要
計測にはコストがかかるので、計測する価値があるかどうかを判断する必要がある
3 部 プロセス
8 章 スタイルガイドとルール
危険を避けるためのルール
ベストプラクティスを強制するためのルール
一貫性を保証するためのルール